-
Notifications
You must be signed in to change notification settings - Fork 14k
Make PointerLike opt-in instead of built-in
#133226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
r? @Nadrieril rustbot has assigned @Nadrieril. Use |
|
r? lcnr |
|
this seems reasonable to me and r=me on the impl after nits, idk about the lang side here 😁 I agree with the backcompat concerns, I feel like layout cycles are something we can definitely solve in the solver |
ccfe08a to
94260bd
Compare
|
I added two FIXMEs. @bors r=lcnr |
94260bd to
228068b
Compare
|
@bors r=lcnr |
The
PointerLiketrait currently is a built-in trait that computes the layout of the type. This is a bit problematic, because types implement this trait automatically. Since this can be broken due to semver-compatible changes to a type's layout, this is undesirable. Also, callinglayout_ofin the trait system also causes cycles.This PR makes the trait implemented via regular impls, and adds additional validation on top to make sure that those impls are valid. This could eventually be
derive()d for custom smart pointers, and we can trust that as a semver promise rather than risking library authors accidentally breaking it.On the other hand, we may never expose
PointerLike, but at least now the implementation doesn't invokelayout_ofwhich could cause ICEs or cause cycles.Right now for a
PointerLikeimpl to be valid, it must be an ADT that isrepr(transparent)and the non-1zst field needs to implementPointerLike. There are also some primitive impls for&T/&mut T/*const T/*mut T/Box<T>.